Most hosts today are multi-homed. Hence, they have multiple paths for connectivity via one or more access technologies. Regular transmission control protocol (TCP)/Internet protocol (IP) communications restrict these multi-homed hosts to use only one of the available interfaces/paths per session, where path is defined as an IP address pair of the source and destination of the path. Internet engineering task force (IETF) is looking into a mechanism, which uses multiple paths between communicating peers simultaneously during a communication session. Request for comments (RFC) 6824, January 2013 proposes a set of extensions to traditional TCP for multipath operations when multiple addresses are available. This protocol is referred to as MPTCP.
The advantages of using multiple paths concurrently comprise:                Improve network resource utilization, e.g. increase bandwidth due to resource pooling        Improve user experience through higher throughput        Allows failover from one interface to another, e.g., mobile client        Allows a single data connection to use several interfaces simultaneously        
FIG. 1 schematically presents a usage scenario for MPTCP, in which two communicating hosts A and B are multi-homed and multi-addressed. Each host provides two separate connections to the Internet offering four different paths between them, A1-B1, A1-B2, A2-B1 and A2-B2.
A traditional TCP connection between the hosts A and B will make use of only one of the available paths whereas MPTCP connection makes use of all the four available paths between hosts A and B. An MPTCP connection is similar to a regular TCP connection and is defined in RFC 6824 as: a set of one or more subflows, over which an application can communicate between two hosts. A subflow is defined in RFC 6824 as: A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similar to a regular TCP connection.
MPTCP is an end-to-end protocol which requires both hosts to support MPTCP to benefit from MPTCP. Since, MPTCP is still in its early stage of deployment, probabilities that every host on the Internet supports MPTCP are very low. To overcome this problem and benefit from MPTCP even though both communicating hosts do not support MPTCP, an MPTCP proxy may be used to convert MPTCP flows to TCP and vice versa.
FIG. 2 schematically presents a scenario in which a UE is MPTCP capable whereas a server, corresponding to Host B, is MPTCP unaware.
The MPTCP-capable UE, corresponding to Host A, is controlled by the operator and sets up several MPTCP subflows to the MPTCP proxy placed in the operator's network. This proxy in turn sets up a single TCP flow to a server on the Internet, corresponding to Host B, which is not MPTCP capable. In the described scenario, the UE which supports MPTCP can still get the benefits of MPTCP although the server at the other end is not aware of MPTCP.
One principle of multipath TCP is to aggregate a set of TCP connections for example over different wireless interfaces such as 3rd generation partnership program (3GPP) and wireless local area network accesses, such as Wi-Fi, or even different simultaneous 3GPP accesses. MPTCP has one main flow and multiple subflows and is capable of distributing load on all interfaces. As the multiplexing of different connections is on TCP level it allows separate congestion control for each subflow.
FIG. 3 shows the differences between standard TCP and MPTCP protocol stacks. The application interface, i.e., the socket application programming interface (API) is unchanged and the main changes are between this API and the IP-layer. MPTCP provides the possibility to fully and maximally utilize different TCP subflows. For example, in the case of one TCP subflow on 3GPP access and another one on a wireless local area network (WLAN) such as Wi-Fi access, the total throughput may be the sum of these subflows.
FIG. 4 shows a user plane protocol architecture example for the case when MPTCP would be utilizing LTE and WLAN/Wi-Fi simultaneously. The LTE subflow is visualized to the left in the figure, whereas the Wi-Fi subflow is visualized to the right in the figure. Additional protocol layers may also be included, for example an 802.11 logical link control (LLC) protocol between the protocol layers IP2 and 802.11 medium access control (MAC) (not shown in FIG. 4).
FIG. 5 shows an example of a MPTCP system in which a UE is simultaneously connected to both LTE and Wi-Fi/WLAN and where a MPTCP subflow is present for each radio access type. The application in the UE has opened up one TCP socket and is sending a “stream of bytes” on the internal API. The MPTCP layer may contain different functionality, one of which may be called MPTCP scheduler, has established two different TCP subflows, subflow 1 via WLAN/Wi-Fi, to the left in the UE, and subflow 2 via LTE, to the right in the UE. Both these subflows are in this example towards a MPTCP proxy node that further communicates with another server using plain TCP, on the right-hand side in the figure.
The MPTCP scheduler is the function that decides how the different packets are mapped to the two subflows. In this example, the MPTCP scheduler is applying “round-robin” scheduling, by alternating between subflow 1 and 2, i.e., first TCP segment is sent on subflow 2, second on subflow 1, third again on subflow 2 etc. Another example is that a MPTCP scheduler uses the subflow with the shortest round-trip time.
MPTCP brings two general advantages, one being that “seamless session continuity at mobility” is enabled, and the other advantage is that throughput aggregation is enabled.
The MPTCP “seamless session continuity at mobility” functionality may also be called “MPTCP session continuity”. The basic principle for this functionality is the concepts of “main” and “backup” subflows. The “main” subflow is normally established first and used for data transmission while the “backup” subflow is established after (or in parallel) to the “main” subflow and not used for data transmission as long as the “main” subflow is operational. If the “main” subflow fails, then the “backup” subflow becomes the “main” subflow and all transmission is moved to the “backup” subflow, in its new status as the “main subflow”. A similar approach applies for the release of the subflows when this functionality is used. This means that when the “main” subflow is released, the related “backup” subflow is also released.
When using MPTCP “seamless session continuity at mobility”, two drawbacks have been identified.
During a MPTCP connection to setup, add or remove a subflow, or a connection to close, control signal exchange will occur on the subflow, even if the subflow is used as “backup path” for “seamless session continuity at mobility” and no data will be transmitted on the backup subflow unless there is problem with the main subflow due to e.g. changed conditions caused by mobility.
If a 3GPP access is used for a backup subflow, and although no data is transmitted, state changes occur on 3GPP side, e.g. for LTE state transitions between RRC_CONNECTED and RRC_IDLE will occur. This may happen for example due to establishment and release of a backup subflow on 3GPP access. An additional example is if the backup subflow is maintained a long time as then even a possible keep-alive signaling on the backup subflow will have similar effect. This results in resource allocation and additional signaling on 3GPP access. This is a drawback since no data may be transmitted on the backup subflow.
In the case a UE is moving and the UE is leaving Wi-Fi for 3GPP access, and the UE is having a “main” subflow on Wi-Fi and possibly a “backup” subflow on 3GPP access, there will be a disconnection time as the MPTCP needs to detect an outage of the Wi-Fi subflow before traffic is moved to 3GPP subflow. The connection time may be even longer in a scenario when a 3GPP subflow has been setup a for a long time, and the UE in the 3GPP access has entered idle state due to inactivity on the 3GPP subflow (and inactivity related to other traffic as well), as in this case the UE needs to also enter “connected” state in the 3GPP access.
FIG. 6 schematically presents an exemplary MPTCP capable system comprising an MPTCP capable network proxy node 62, a controller of a first radio access type (RAT) 61, a controller of a second RAT, and a MPTCP capable user equipment (UE) 68, according to the prior art.
There is thus a need for a solution addressing one or more of these issues as discussed above.